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Abstract 



To deal with failures as simply as possible, we propose a new foun- 
dation for the core (untyped) C, which is based on a new logic called 
task logic or imperative logic. We then introduce a sequential-disjunctive 
' statement of the form S : R. This statement has the following semantics: 

I execute S and R sequentially. It is considered a success if at least one 

. of 5", i? is a success. This statement is useful for dealing with inessential 

' errors without explicitly catching them. 

1 Introduction 

' Imperative programming is an important modern programming paradigm. Suc- 

00 ! cessful languages in this paradigm includes C and Java. Despite much attrac- 

^^O ' tiveness, imperative languages have traditionally lacked fundamental notion of 

^SJ ! success/failure for indicating whether a statement can be successfully completed 

or not. Lacking such a notion, imperative programming relies on nonlogical, 
awkward devices such as exception handling to deal with failures. One major 
problem with exception handling is that the resulting language becomes com- 
plicated and not easy to use. 

To deal with failures as simply as possible, we propose a new foundation for 
the core (untyped) C, which is based on a new logic called task logic [2 [2] or 
' imperative logic. The task logic expands the traditional t/f (true/false) so as to 

include T/ F(success/failure). The task logic interprets each statement as T/F, 
depending on whether it can be successfully completed or not. The premature 
exit of a statement due to failures can be problematic. To avoid this, we adopt 
"all-or-nothing" semantics discussed in [3] to guarantee atomicity. Thus, if a 
failure occurs in the couse of executing a statement, we assume that the machine 
rolls back partial updates. 

We can then extend this "logic-based" C with other useful logical operations. 
To improve robustness, we introduce a sequential-disjunctive statement of the 
form S : R. Here, to avoid complications, we assume that S and R are indepen- 
dent of each other, i.e., no variables appear in both S and R. This statement 
has the following semantics: execute S and R sequentially. It is considered a 
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success if at least one of S,R is a success. This statement generates less ex- 
ceptions, is easier to succeed, and hence is more robust than other statements. 
This statement has the effect of reducing the number of exceptions to be dealt 
with without catching them. It is useful for dealing with inessential errors that 
can be ignored. For example, the statement 5" : true has the effect of erasing 
all the possible exceptions raised in the course of executing S so that none of 
these exceptions can have further interactions with the environment. 

We also introduce a choice-disjunctive statement of the form S else R which 
is a logical version of the try S catch R statement. This statement has the 
following semantics: execute S. If it is a success, then do nothing. If it fails, 
execute R. 

The remainder of this paper is structured as follows. We describe the new 
language in the next section. In Section [31 we present some examples. 
Section [3] concludes the paper. 

2 The Language 

The language is a subset of the core (untyped) C with some extensions. It is 
described by G- and I?-formulas given by the syntax rules below: 

G::= t\f\A\x^E\G-G\G:G\G else G 
D : = A=^G \ yx D 

In the rules above, A represents an atomic procedure definition of the form 
p(ti, . . . , A ZJ-formula is called a procedure definition. / denotes false 
which correponds to a user-thrown exception. 

In the transition system to be considered, G-formulas will function as the 
main program (or statements), and a set of £)- formulas enhanced with the ma- 
chine state (a set of variable-value bindings) will constitute a program. 

We will present an operational semantics for this language via a proof theory. 
The rules are formalized by means of what it means to execute the main task G 
from a program V. These rules in fact depend on the top-level constructor in 
the expression, a property known as uniform provability [5j. Below the notation 
D-jV denotes {D} U V but with the D formula being distinguished (marked 
for backchaining) . Note that execution alternates between two phases: the 
goal-reduction phase (one without a distinguished clause) and the backchaining 
phase (one with a distinguished clause). The notation S sand R denotes the 
following: execute S and execute R sequentially. It is considered a success if 
both executions succeed. The notation not{) denotes a failure. 

Definition 1. Let G be a main task and let "P be a program. Then the notion 
of executing {V, G) successfully and producing a new program V'- ex{V, G, T") 
- is defined as follows: 

(1) ex{V,t,P). % True is always a success. 

(2) ex{{A = Gi);r,A) if exiP, Gi) and ex{D; V, A). 

(3) ea;(VxZ3; "P, A) if ex^t/xjO^V , A). % argument passing 
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(4) exiV , A) a D e r and ex(D; A). % a procedure call 

(5) ex{'P,x = E,r^{{x,E')}) if eval{r,E,E'). % l+) denotes a set union but 
(x, V) in V will be replaced by (a;, £"). 

(6) ex{r,Gi;G2,r2) if ea;(P, d, Pi) sand 
ex(Pi,G2,P2). 

(7) ex(P,Gi :G2,P2) if ea;(7', Gi, Pi) sand 
ex{'P,G2,V2)- % both Gi and G2 succeed. 

(8) ea;(P,Gi : G2,P2) if not{ex{r,Gi,Pi)) sand 
ex{'P,G2,V2)- % only G2 succeeds. 

(9) ea;(7',Gi :G2,Pi) if ea;(P, Gi, Pi) sand 
not(ea;(P, G2, ^2))- % only Gi succeeds. 

(10) ex(P,Gi e/se G2,Pi) if ea;(P,Gi,Pi) 

(11) ea;(P,Gi else G2,V2) if not{ex{V ,Gi,Vi)) sand 
ea;(P,G2,P2)). 

If ex{V,G,'Pi) has no derivation, then the machine returns F, the failure. For 
example, ex{V, f,Vi) is a failure because it has no derivation. 

3 Examples 

So far, we have considered only one kind of failures. In reality, there are many 
kinds of failures in imperative programming. Thus, we need to expand / to 
include /(e) for a user-thrown exception e. The notion of exception trees [3] 
is then useful to organize failures, similar to a file system in Unix and similar 
to an exception class in Java. Below we assume that the machine returns an 
exception tree stored in Failtree rather than just F. We also assume that /F 
is the root directory of Failtree and /F/usr is the directory for user-thrown 
failures. An exception can be derived from the parent exception. Exception 
trees allow the programmer to select to deal with failures at varying degrees of 
specificity. An example of the use of this construct is provided by the following 
program which contains some basic file-handling rules. 

main 

openfileO; readfile{) 
else 

case Failtree of 
/F/sys: ... 
/F/usr /EOF : . . .; 
X = f actoriaHA) 

readfileQ = {read{) ^ -1); . . . else f{EOF) 

Our language makes it possible to simplify the program if some statements 
are inessential. For example, the following program explicitly tells the machine 
that the statement openfileQ] readfile{) is inessential and optional and thus it 
is OK not to perform the statement if it fails. 
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main 

{openfile{);readfile{)) : 
X = factorial{4) 

readfileQ = {readQ 7^ -1); . . . else f{EOF) 

4 Conclusion 

In this paper, we have considered an extension to the core C with disjunctive 
statements. This extension allows statements of the form S : R where S, R are 
statements. These statements are particularly useful for dealing with inessential 
statements. 
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